This relates to the operation of software under a virtualization technology (VT) environment.
In a VT environment, such as the Intel VT or AMD Pacifica, an infrastructure may be provided to execute applications in an isolated and protected partition, called the service partition, using the VT capability. The operating system that is visible to end users runs in another partition, called the user partition. For example, a firewall application running in service partition is forwarding the inspected/verified data packets to the user partition. A typical flow of a network packet consist of a) processing and inspection of the network packet by the firewall application in service partition, and b) subsequent forwarding of the network packet to the user partition through the inter-communication channel. The network packet eventually reaches the end-user application running in user partition (as it would happen in a non-VT environment).
In a particular VT environment, Windows CE can be used in the service partition and Windows XP in the user partition. The control flow of boot process can be summarized as follows: a) Basic input/output system passes the control to VT loader; b) VT loader loads itself and prepares the environments for the service partition and user partition for both guests Windows CE and Windows XP respectively; c) VT loader launches Windows CE in service partition, Windows CE completes its boot, and requests VT loader to launch Windows XP; d) VT loader then launches Windows XP and Windows XP starts booting.
During initial stages of a boot process, the XP operating system uses different basic input/output system services as usual. However, the XP operating system is unaware that it is running within a partition isolated and supervised by another entity. Although the control flow of the XP operating system in the VT aware environment remains identical to that of the non-VT environment, the underlying hardware environment differs as far as the device ownership is concerned.
Typically, devices are fully owned by one operating system or guest running in a particular partition (service partition or user partition), and, therefore, are isolated from one another. For example, network controllers may be owned by the Windows CE operating system running in service partition, that handles all incoming and outgoing packets, while storage devices, like hard disks, may be owned by the XP operating system running in user partition. However, some devices, like programmable interrupt controller, may be shared between the two operating systems and are thereby exposed to both guests via the underlying software models.
When an interrupt request is shared by different devices, owned by different guests, in level-triggered interrupt environments, the interrupt may be conveyed to both guests under the assumption that the service routine of both guests will be invoked; the service routine of a particular guest will check the interrupt source for the device it controls; if several devices raise a shared interrupt request simultaneously, all devices will be checked as possible interrupt sources and serviced as necessary; and if a guest detects that the interrupt source for the device it controls, it will service the interrupt or, otherwise, it will ignore the interrupt by sending an end of interrupt.
The basic input/output system (BIOS) installs a default interrupt request handler for all hardware interrupts. If no other entity installs a handler for a particular interrupt request, the basic input/output system default interrupt service routine remains as the only active interrupt handler for the concerned interrupt request. In a shared interrupt environment, when an entity installs a handler for a particular interrupt request, the concerned handler is installed in a chained fashion so that the last installed handler gets control first on the occurrence of the concerned interrupt request and the basic input/output system default interrupt service routine remains at the bottom of the interrupt handler chain. Thus, if no handler claims and services the generated interrupt request, the basic input/output system default interrupt service routine eventually gets control and finds the interrupt request that has been generated, but not claimed and, hence, not serviced by anybody, and disables the request, treating it like a spurious interrupt.